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Guidelines for the Secure Operation of the Internet 


Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard. Distribution of this memo is 
unlimited. 

Preamble 


The purpose of this document is to provide a set of guidelines to aid 
in the secure operation of the Internet. During its history, the 
Internet has grown significantly and is now quite diverse. Its 
participants include government institutions and agencies, academic 
and research institutions, commercial network and electronic mail 
carriers, non-profit research centers and an increasing array of 
industrial organizations who are primarily users of the technology. 
Despite this dramatic growth, the system is still operated ona 
purely collaborative basis. Each participating network takes 
responsibility for its own operation. Service providers, private 
network operators, users and vendors all cooperate to keep the system 
functioning. 


It is important to recognize that the voluntary nature of the 
Internet system is both its strength and, perhaps, its most fragile 
aspect. Rules of operation, like the rules of etiquette, are 
voluntary and, largely, unenforceable, except where they happen to 
coincide with national laws, violation of which can lead to 
prosecution. A common set of rules for the successful and 
increasingly secure operation of the Internet can, at best, be 
voluntary, since the laws of various countries are not uniform 
regarding data networking. Indeed, the guidelines outlined below 
also can be only voluntary. However, since joining the Internet is 
optional, it is also fair to argue that any Internet rules of 
behavior are part of the bargain for joining and that failure to 
observe them, apart from any legal infrastructure available, are 
grounds for sanctions. 
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Introduction 


These guidelines address the entire Internet community, consisting of 
users, hosts, local, regional, domestic and international backbone 
networks, and vendors who supply operating systems, routers, network 
management tools, workstations and other network components. 


Security is understood to include protection of the privacy of 
information, protection of information against unauthorized 
modification, protection of systems against denial of service, and 
protection of systems against unauthorized access. 


These guidelines encompass six main points. These points are 
repeated and elaborated in the next section. In addition, a 
bibliography of computer and network related references has been 
provided at the end of this document for use by the reader. 


Security Guidelines 


(1) Users are individually responsible for understanding and 
respecting the security policies of the systems (computers and 
networks) they are using. Users are individually accountable 
for their own behavior. 


(2) Users have a responsibility to employ available security 
mechanisms and procedures for protecting their own data. They 
also have a responsibility for assisting in the protection of 
the systems they use. 


(3) Computer and network service providers are responsible for 
maintaining the security of the systems they operate. They are 
further responsible for notifying users of their security 
policies and any changes to these policies. 


(4) Vendors and system developers are responsible for providing 
systems which are sound and which embody adequate security 
controls. 


(5) Users, service providers, and hardware and software vendors are 
responsible for cooperating to provide security. 


(6) Technical improvements in Internet security protocols should be 
sought on a continuing basis. At the same time, personnel 
developing new protocols, hardware or software for the Internet 
are expected to include security considerations as part of the 
design and development process. 
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Elaboration 


(1) Users are individually responsible for understanding and 
respecting the security policies of the systems (computers and 
networks) they are using. Users are individually accountable 
for their own behavior. 


Users are responsible for their own behavior. Weaknesses in 

the security of a system are not a license to penetrate or 

abuse a system. Users are expected to be aware of the security 
policies of computers and networks which they access and to 
adhere to these policies. One clear consequence of this 
guideline is that unauthorized access to a computer or use of a 
network is explicitly a violation of Internet rules of conduct, 
no matter how weak the protection of those computers or networks. 


There is growing international attention to legal prohibition 
against unauthorized access to computer systems, and several 
countries have recently passed legislation that addresses the 
area (e.g., United Kingdom, Australia). In the United States, 
the Computer Fraud and Abuse Act of 1986, Title 18 U.S.C. 
section 1030 makes it a crime, in certain situations, to access 
a Federal interest computer (federal government computers, 
financial institution computers, and a computer which is one of 
two or more computers used in committing the offense, not all of 
which are located in the same state) without authorization. 
Most of the 50 states in the U.S have similar laws. 


Another aspect of this part of the policy is that users are 
individually responsible for all use of resources assigned to 
them, and hence sharing of accounts and access to resources is 
strongly discouraged. However, since access to resources is 
assigned by individual sites and network operators, the 
specific rules governing sharing of accounts and protection of 
access is necessarily a local matter. 


(2) Users have a responsibility to employ available security 
mechanisms and procedures for protecting their own data. They 
also have a responsibility for assisting in the protection of 
the systems they use. 


Users are expected to handle account privileges ina 
responsible manner and to follow site procedures for the 
security of their data as well as that of the system. For 
systems which rely upon password protection, users should 
select good passwords and periodically change them. Proper 
use of file protection mechanisms (e.g., access control lists) 
so as to define and maintain appropriate file access control 
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is also part of this responsibility. 


(3) Computer and network service providers are responsible for 
maintaining the security of the systems they operate. They are 
further responsible for notifying users of their security 
policies and any changes to these policies. 


A computer or network service provider may manage resources on 
behalf of users within an organization (e.g., provision of 
network and computer services with a university) or it may 
provide services to a larger, external community (e.g., a 
regional network provider). These resources may include host 
computers employed by users, routers, terminal servers, personal 
computers or other devices that have access to the Internet. 


Because the Internet itself is neither centrally managed nor 
operated, responsibility for security rests with the owners and 
operators of the subscriber components of the Internet. 
Moreover, even if there were a central authority for this 
infrastructure, security necessarily is the responsibility of 
the owners and operators of the systems which are the primary 
data and processing resources of the Internet. 


There are tradeoffs between stringent security measures at a 
site and ease of use of systems (e.g., stringent security 
measures may complicate user access to the Internet). If a site 
elects to operate an unprotected, open system, it may be 
providing a platform for attacks on other Internet hosts while 
concealing the attacker’s identity. Sites which do operate 
open systems are nonetheless responsible for the behavior of 
the systems’ users and should be prepared to render assistance 
to other sites when needed. Whenever possible, sites should 
try to ensure authenticated Internet access. The readers are 
directed to appendix A for a brief descriptive list of elements 
of good security. 


Sites (including network service providers) are encouraged to 
develop security policies. These policies should be clearly 
communicated to users and subscribers. The Site Security 
Handbook (FYI 8, RFC 1244) provides useful information and 
guidance on developing good security policies and procedures 
at both the site and network level. 


(4) Vendors and system developers are responsible for providing 


systems which are sound and which embody adequate security 
controls. 
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A vendor or system developer should evaluate each system in 
terms of security controls prior to the introduction of the 
system into the Internet community. Each product (whether 
offered for sale or freely distributed) should describe the 
security features it incorporates. 


Vendors and system developers have an obligation to repair 
flaws in the security relevant portions of the systems they 
sell (or freely provide) for use in the Internet. They are 
expected to cooperate with the Internet community in 
establishing mechanisms for the reporting of security flaws and 
in making security-related fixes available to the community in 
a timely fashion. 


(5) Users, service providers, and hardware and software vendors are 
responsible for cooperating to provide security. 


The Internet is a cooperative venture. The culture and 
practice in the Internet is to render assistance in security 
matters to other sites and networks. Each site is expected to 
notify other sites if it detects a penetration in progress at 
the other sites, and all sites are expected to help one another 
respond to security violations. This assistance may include 
tracing connections, tracking violators and assisting law 
enforcement efforts. 


There is a growing appreciation within the Internet community 
that security violators should be identified and held 


accountable. This means that once a violation has been detected, 
sites are encouraged to cooperate in finding the violator and 
assisting in enforcement efforts. It is recognized that many 


sites will face a trade-off between securing their sites as 
rapidly as possible versus leaving their site open in the hopes 
of identifying the violator. Sites will also be faced with the 
dilemma of limiting the knowledge of a penetration versus 
exposing the fact that a penetration has occurred. This policy 
does not dictate that a site must expose either its system or 
its reputation if it decides not to, but sites are encouraged 
to render as much assistance as they can. 


(6) Technical improvements in Internet security protocols should be 
sought on a continuing basis. At the same time, personnel 
developing new protocols, hardware or software for the Internet 
are expected to include security considerations as part of the 
design and development process. 


The points discussed above are all administrative in nature, 
but technical advances are also important. Existing protocols 
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and operating systems do not provide the level of security that 
is desired and feasible today. Three types of advances are 
encouraged: 


(a) Improvements should be made in the basic security 
mechanisms already in place. Password security is 
generally poor throughout the Internet and can be 
improved markedly through the use of tools to administer 
password assignment and through the use of better 
authentication technology. At the same time, the 
Internet user population is expanding to include a 
larger percentage of technically unsophisticated users. 
Security defaults on delivered systems and the controls 
for administering security must be geared to this growing 
population. 


(b) Security extensions to the protocol suite are needed. 
Candidate protocols which should be augmented to improve 
security include network management, routing, file 
transfer, telnet, and mail. 


(c) The design and implementation of operating systems should 
be improved to place more emphasis on security and pay 
more attention to the quality of the implementation of 
security within systems on the Internet. 


APPENDIX A 


Five 


(1) 


Pethia, 


areas should be addressed in improving local security: 


There must be a clear statement of the local security policy, 
and this policy must be communicated to the users and other 
relevant parties. The policy should be on file and available 
to users at all times, and should be communicated to users as 
part of providing access to the system. 


Adequate security controls must be implemented. At a minimum, 
this means controlling access to systems via passwords, 
instituting sound password management, and configuring the 
system to protect itself and the information within it. 


There must be a capability to monitor security compliance and 
respond to incidents involving violation of security. Logs of 
logins, attempted logins, and other security-relevant events 
are strongly advised, as well as regular audit of these logs. 
Also recommended is a capability to trace connections and other 
events in response to penetrations. However, it is important 
for service providers to have a well thought out and published 


Crocker, & Fraser [Page 6] 


RFC 1281 Guidelines for the Secure Operation November 1991 


policy about what information they gather, who has access to it 
and for what purposes. Maintaining the privacy of network 
users should be kept in mind when developing such a policy. 


(4) There must be an established chain of communication and control 
to handle security matters. A responsible person should be 
identified as the security contact. The means for reaching the 
security contact should be made known to all users and should 
be registered in public directories, and it should be easy for 
computer emergency response centers to find contact information 
at any time. 


The security contact should be familiar with the technology and 
configuration of all systems at the site or should be able to 
get in touch with those who have this knowledge at any time. 
Likewise, the security contact should be pre-authorized to make 
a best effort to deal with a security incident, or should be 
able to contact those with the authority at any time. 


(5) Sites and networks which are notified of security incidents 
should respond in a timely and effective manner. In the case 
of penetrations or other violations, sites and networks should 
allocate resources and capabilities to identify the nature of 
the incident and limit the damage. A site or network cannot be 
considered to have good security if it does not respond to 
incidents in a timely and effective fashion. 


If a violator can be identified, appropriate action should be 
taken to ensure that no further violations are caused. Exactly 
what sanctions should be brought against a violator depend on 
the nature of the incident and the site environment. For 
example, a university may choose to bring internal disciplinary 
action against a student violator. 


Similarly, sites and networks should respond when notified of 


security flaws in their systems. Sites and networks have the 
responsibility to install fixes in their systems as they become 
available. 
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Security Considerations 


If security considerations had not been so widely ignored in the 
Internet, this memo would not have been possible. 
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